In modern systems used today in the field of medical data processing, provision is made for the captured data to be in digital form and accordingly also to be processed further in digital form using electronic appliances. The wide variety of different processing processes in the clinical environment means that there is a large number of different taskflows for performing particular activities. One example which may be mentioned here are taskflows which are required for image data capture, for post-processing the captured image data, and taskflows which are required for archiving image data. A taskflow usually requires a sequence of predefined method steps and input data in order to be able to perform the relevant tasks or activities. The data are usually medical data, such as particularly image data, patient-related data records or text data which are required for an examination or a report. A taskflow is executed on any desired computer network or a portion thereof and is equipped with interfaces in order to allow data interchange with external systems. The input and output data are usually provided by what is known as an RIS system. There is a further interface to PACS systems (PACS: Picture Archiving Communication System).
In the medical or clinical field of use, there are a large number of requirements which make a system architecture relatively complex. On the one hand, there are a large number of central processing stations which are equipped with high processor power and high memory requirements in order to execute complex processing steps, such as post-processing processes. On the other hand, it is also meant to be possible to be able to operate and to use clients within the system, which, by way of example, comprise small handhelds or other small appliances, such as PDAs, and are available to the doctor, e.g. in the course for a visit. The functionalities which are needed in the present example of a visit, such as the capture and storage of data recorded for the visit and, by way of example, access to medication data, are meant to be available on these appliances, inter alia. Furthermore, it is necessary for these data which have been captured by the appliance to be transmitted to the central system at a later time. In this context, it is necessary to ensure that the data are kept basically consistent in order to prevent different instances or versions of one and the same data record from existing in the system, which could result in sometimes serious consequent errors.
Furthermore, it should be possible for all appliances connected to the system to be able to be used at any time regardless of the network resources and therefore also to be able to be operated in an online mode and in an offline mode.
In the clinical field of use with different service times, there are normally a large number of people who undertake the execution and/or monitoring of a particular taskflow. Furthermore, it is possible for one and the same person to undertake and perform different tasks (e.g. the task of an examining doctor and the task of a scheduler for future examinations). Thus, it is necessary to be able to adapt the architecture of the system very flexibly to the different processing instances, to the respective users of the processing instances and/or to the respective applications of the users. Furthermore, a change of role needs to be supported, i.e. different users simultaneously handle portions of the same taskflow with the option of interrupting the flow and continuing it on another computer.
In previous systems known from the prior art, there are no opportunities to generate a taskflow dynamically. The configuration options for particular activities were therefore very restricted. By way of example, it was always necessary to perform a first activity, particularly a selection functionality, before further tasks could be undertaken. Furthermore, the final activity to be performed in a taskflow always had to be a data transfer, that is to say that the data processed by way of the taskflow had to be forwarded to another instance. This meant that the basic flow of a taskflow was unnecessarily very restricted.
Disadvantageously, the opportunities to provide online processing and offline processing at particular processing stations were likewise very restricted. Particular processing stations or processing instances were equipped with online access, while other instances had no access to the network. These provisions were normally rigid. It is therefore desirable to have a system architecture which allows a further degree of flexibilization by virtue of one and the same processing instance being able to be operated in different modes of operation, particularly in an online mode or in an offline mode. A change between the aforementioned modes shall also be supported without inconsistencies or even the loss of data arising.
Since the applications are frequently relatively complex tasks, it may be necessary in certain situations to interrupt a processing process. Interruption of a processing process and resumption possibly taking place at a later time were not possible in the previous systems from the prior art. It is therefore desirable to have a system architecture which allows further flexibilization for the execution of a processing process by virtue of the processing process being able to be interrupted and possibly resumed at a later time. In this context, further flexibility should involve the processing process being able to be started on a free choice of processing instance and not necessarily having to be started on that instance on which the taskflow was interrupted.